Organizational Structure
Establish functional verticals (preferred) and limited cross-cutting horizontals
The Harvard Business Review article "How Apple Is Organized for Innovation" lays out the case for functionally-oriented verticals but it’s fundamentally simple (paraphrased):
Decision making and seniority is best correlated with expertise.
If you’re a great person, why do you want to work for someone you can’t learn anything from?!
The worst organizations are the ones where people look to their leaders to see incompetence and lack of expertise - both in terms of outcomes, and destruction of morale. This is more likely to occur when the organizational structure isn’t designed to reflect it, e.g. a hardware engineer leading an Engineering department and supposedly leading software engineers. Rarely do we even see the best case where the person in charge is smart enough to step back and not interfere in something they’re ignorant of. The Apple organization model essentially minimized this occurrence by having it only occur at one point - around Steve Jobs.
When designing your organizational structure for maximum performance, you need to red-flag points where people of no expertise have power over others.
Some organizations create cross-cutting horizontals e.g. a Project Management department, alongside verticals like Hardware Engineering and Production. This is problematic for multiple reasons:
-
The horizontal function interferes in the verticals where they have no expertise, causing dysfunction. A project management specialist rarely knows anything about, say, mechanical engineering and manufacturing.
-
The horizontal function gets frustrated at inability to exert control over the verticals.
If you must have functional horizontals, the best way to clarify their position as drivers of best practice with a "light touch" approach but no formal authority over the verticals.
Don’t create Engineering departments
Engineering doesn’t exist… and that’s not a play on words of the YouTube channel "Baseball Doesn’t Exist".
-
There’s no degree in 'creating stuff'.
-
There is no 'Institute of Engineering'.
There is no such discipline as 'engineering'. There is:
-
Aerospace and Aerothermal Engineering
-
Bioengineering
-
Civil, Structural and Environmental Engineering
-
Electrical and Electronic Engineering
-
Electrical and Information Sciences
-
Energy, Sustainability and the Environment
-
Information and Computer Engineering
-
Instrumentation and Control
-
Mechanical Engineering
The skills, techniques, models, history and ideas of the aforementioned disciplines are so broad in scope and diverse, that students specialize before even getting out of 3-4 years of undergraduate study. Then on top of that, they require decades of real-world experience and learning, in order to build expertise.
There are rare instances of polymathy, but the practical limitations on time required to learn deeply and gain experience means that claims to be able to span these disciplines are limited at best, and delusional at worst. Don’t put a software engineer in charge of building highways overnight - it won’t end well. It is extremely unlikely that an 'engineer' is a modern day Leonardo da Vinci.
Functional verticals should separate the engineering disciplines, or at a minimum separate the 'world of atoms' (physical space) from the 'world of bits' (information space), which have fundamentally different dynamics, rules, constraints and bodies of knowledge.
Define role profiles
Leadership should author role profiles, whose contents:
-
Bring clarity to the human requirements for roles
-
When reused, create alignment across multiple workflows.
They should be structured at the top-level consistent with individual performance i.e. { Character, Expertise, Success }
The contents of role profiles can be reused in multiple areas, creating alignment:
-
In recruitment ads.
-
When evaluating role candidates (new recruitment, internal promotion).
-
To guide individual performance reviews.
-
Identify gaps in expertise that need to be filled (when built into an expertise map).
-
Identify single points of failure (when built into an expertise map) - individuals whose absence/departure cripples productivity.
Map expertise
There’s a crappy term for a map of expertise in an organization - 'Skills Matrix'. The plain English, keep-it-simple name in the Mixed Management Methodology is 'Expertise Map'.
As a reminder, expertise is one of the components of individual performance.
Design the map
When structuring your expertise map, break it down hierarchically by { discipline, product/service, technologies, business domain } according to your specific context e.g.
-
Software Engineering (discipline)
-
OOP
-
Recursion
-
-
Our SaaS software (product/service)
-
Account management
-
Catalogue navigation
-
-
Technologies (technologies)
-
C#
-
ASP.NET
-
-
B2C retail (business domain)
-
Data protection law
-
The structure should be aligned with the expertise component of the relevant role profiles.
Populate the map
The most effective and efficient approach to populating the map is self-assessment. Send out a form for/access to the spreadsheet and have people self-rate their expertise from [0, 4] (as per individual performance rating).
Self-assessment is best, because:
-
Any approach will dependent on subjective opinion anyway. The individual in question is as informed as anyone else.
-
Making the map contents open and accessible will increase the likelihood of surfacing errors/deception "No way Person X has expertise of 4 on Topic A!"
-
Any other approach has the increased likelihood of bottle necking. With self-assessment, the burden is being maximally distributed.
Use the results
Once the map has been populated:
-
Analysis of the results (particularly colour coding the ratings) may highlight areas of weakness/single-points-of-failure, or under-utilized expertise.
-
The results can be used as input into personal development strategies.
Don’t fall for the dogma of full-time specialist roles
In some conventional software engineering methodologies, such as Scrum or Scaled Agile, some full-time specialist roles are considered mandatory (or strongly pushed), including Architect, Product Manager (Product Leader?), UI Designer, Scrum Master, Test Engineer, Technical Writer and so on.
These are actually responsibilities (or activities to be done), and don’t dogmatically have to be full-time roles. It’s perfectly reasonable for a responsibility to be covered without adding specialist roles. Within a given set of circumstances, a senior-level software engineer may be perfectly capable of performing the activities of a Product Manager, without overburdening or falling short in expertise… it depends.
Following the idea of functional verticals, consider this general form of role title:
"<Seniority> <Discipline> [- <Specialism>]" e.g. "Principal Software Engineer - Frontend"
Product Owner/Manager
Product management (leadership) roles are problematic. There’s a great depth of learning in creating and taking care of things. Career product people tend to lack this depth, and there’s something distinctly 'career consultant' about their general lack of competence. One could argue they bring domain expertise - sure, but can they put it to good use? Can someone effectively tell others what to create, if they don’t have expertise in how to create? (no)
Should you create a product leadership role - with the decision making powers it entails - or do you just need:
-
A 'Subject Matter Expert' who can assist the people who actually create? (but without the product decision rights)
-
To develop greater business domain understanding in the creators?
Scrum Master
In other cases, full-time specialist roles can be positively destructive. The dogma of the Scrum Master is one of the worst things to ever happen to software engineering. The name itself is steeped in Scrum dogma.
If you have a full-time Scrum Master with no meaningful expertise creating software (apprentice, journeyman craftsman), which seems to be disturbingly common, what help are they actually to senior engineer with decades of experience actually doing it? If a Scrum Master role exists, it’s most often a reflection of:
-
The leadership of Software Engineering is incompetent, because they can’t do their job of implementing, driving and maintaining best practice.
-
The organization’s leadership is dogmatically adhering to a methodology irrespective of what the realized benefits are, thus wasting money.
All the activities a Scrum Master is supposed to perform should be covered by competent people in leadership roles, and before attempting to plug the gap with another person, there should be a serious conversation about why the gap exists.
Best practice is understood and implemented by competent practitioners.
Technical Writer
The best people to explain what a product does, how it works etc. are the people who designed and created it.
There’s really no way around that fact (otherwise you’ll be doing reverse engineering).
A full-time specialist Technical Writer role can raise the standard of the writing and provide extra bandwidth to write, but there’s no silver bullet to avoid the need for the creators to write the first draft. Seems obvious but you’d be surprised at how ignorant people can be of the obvious.
Staff in adequate numbers for your expectations
The world of unlimited resources is obviously a fiction for any organization. We live in an objective universe on a closed ball in space with a finite number of people available and a finite amount and distribution of expertise, and so on.
I’ve never seen a silver bullet for understanding what 'adequate' means in terms of human resources. It’s a highly context-specific problem whose input variables are many and varied, such as the business domain, the nature of the product/service portfolio, the cash resources, the landscape of competitive organizations, but to name a few.
All you can really do to plan staffing is rely on past experience and reason-in-the-context, then let the chips fall where they may, whilst being responsive to new learning and changing conditions.
In some cases, there are simple rules of thumbs available e.g. in IT, ratio of organizational headcount to IT department headcount.
What should be much easier to identify with even a modicum of experience and reasoning ability, are minimum levels of resourcing necessary to achieve goals, below which the staff will be overworked, overstressed and likely to leave, leading to project/function collapse. As is often seen in phase dynamics, there’s a period of sustained stress where no problem is apparent from a distance, then sudden change/collapse.
A natural consequence of the inevitable limits of available resources, is the need to limit expectations of what may be achieved in a given timeframe.
You’ll notice that all of this requires expertise. Without expertise, no reasonable understanding of what’s required can be formed, nor what’s possible, nor the unavoidable reality of uncertainty, risk, and objective limits. Leadership/management without expertise or reasoning ability will inevitably behave unreasonably, and it’s incredible how common this is.